Method and system for determining confidence in a digital transaction

ABSTRACT

The present invention provides systems and methods utilizing tokens to assign or mitigate risk. A software token is provided that associates a secret—such as a private key or password—with risk factors involved in protecting that secret from illicit access. The token may include an indication or calculation of the “overall risk of compromise” (OROC), generally represented as an overall trust metric, associated with the secret. This token can then be used to inform system operators or third parties of the confidence of a given system transaction that depends on the secret. A third party can then take whatever actions it deems appropriate according to the estimated risk. For example, in one embodiment of the present invention, the risk factor is used to deny a transaction if the risk is deemed to great—that is if the risk factor is greater than a predetermined (or sufficient) value.

RELATED APPLICATIONS

[0001] This application further relates to the following co-pendingapplications:

[0002] U.S. application Ser. No. ______, filed ______, entitled“BIOMETRICALLY ENHANCED DIGITAL CERTIFICATES AND SYSTEM AND METHOD FORMAKING AND USING” (Attorney Docket No. A-70596/RMA/JML);

[0003] U.S. application Ser. No. ______, filed ______, entitled “SECURENETWORK AND NETWORKED DEVICES USING BIOMETRICS” (Attorney Docket No.A70595/RMA/JML); and

[0004] U.S. application Ser. No. ______, filed ______, entitled “METHODAND SYSTEM FOR BIOMETRIC IMAGE ASSEMBLY FROM MULTIPLE PARTIAL BIOMETRICFRAME SCANS” (Attorney Docket No. A-70591/RMA/JML); all of which arehereby incorporated by reference.

[0005] This application claims the benefit under 35 U.S.C. §119 and/or35 U.S.C. §120 of the filing date of: U.S. Provisional ApplicationSerial No. 60/305,120, filed Jul. 12, 2001, which is hereby incorporatedby reference, and entitled SYSTEM, METHOD, DEVICE AND COMPUTER PROGRAMFOR NON-REPUDIATED WIRELESS TRANSACTIONS; U.S. patent application Ser.No. 10/099,554 filed Mar. 13, 2002 and entitled SYSTEM, METHOD, ANDOPERATING MODEL FOR MOBILE WIRELESS NETWORK-BASED TRANSACTIONAUTHENTICATION AND NON-REPUDIATION; and U.S. patent application Ser. No.10/099,558 filed Mar. 13, 2002 and entitled FINGERPRINT BIOMETRICCAPTURE DEVICE AND METHOD WITH INTEGRATED ON-CHIP DATA BUFFERING; eachof which applications are incorporated by reference herein.

FIELD OF THE INVENTION

[0006] The present invention relates generally to the field of methods,computer programs and computer program products, devices, and systemsfor encryption systems, especially public key infrastructure (PKI)systems, and also to the field of biometrics, especially but not limitedto biometrics such as human fingerprints and human voiceprints.

BACKGROUND OF THE INVENTION

[0007] The security and integrity of information systems depends in parton authentication of individual users—accurately and reliablydetermining the identity of a user attempting to use the system. Once auser is authenticated, a system is then able to authorize the user toretrieve certain information or perform certain actions appropriate tothe system's understanding of the user's identity. Examples of suchactions include downloading a document, completing a financialtransaction, or digitally signing a purchase.

[0008] Numerous methods have been developed for authenticating users.Generally, as will be understood by those skilled in the art,authentication methods are grouped into three categories, also calledauthentication factors: (1) something you know—a secret such as apassword or a PIN or other information; (2) something you have—such as asmartcard, the key to a mechanical lock, an ID badge, or other physicalobject; and (3) something you are—a measure of a person such as afingerprint or voiceprint. Each method has advantages and disadvantagesincluding those relating to ways that a system may be fooled intoaccepting a normally unauthorized user in cases where, for example, apassword has been guessed or a key has been stolen.

[0009] The third category above—referred to herein as ‘something youare’ authentication methods—are the subject of the biometrics field.Biometric identification is used to verify the identity of a person bymeasuring selected features of some physical characteristic andcomparing those measurements with those filed for the person in areference database or stored in a token (such as a smartcard) carried bythe person. Physical characteristics that are used today includefingerprints, voiceprints, hand geometry, the pattern of blood vesselson the wrist or on the retina of the eye, the topography of the iris ofthe eye, facial patterns, and the dynamics of writing a signature ortyping on a keyboard. Biometric identification methods are widely usedtoday for securing physical access to buildings and securing datanetworks and personal computers.

[0010] A secure system is based upon either a mutually-shared secret ora private key of a public-private key pair. During the enrollmentprocess, the secret is first selected or created, then agreed upon andstored for later use. There are generally four major sources of riskassociated with the secret being compromised: (1) the secret can beguessed by an unauthorized user; (2) the secret was observed by anunauthorized user during creation or subsequent transmission; (3) thestored secret can be retrieved and employed by an unauthorized userafter creation; and/or (4) the stored secret was issued to the wrongparty.

[0011] Each of the above broad categories has its own specific riskfactors depending on the type of secret, where and how it is stored andhow it is created. For example, the risk of guessing is dependent on avariety of factors including, but not limited to, the type of secret(for example, a password, a private PKI key, a symmetric key, or thelike), the length of the secret (for example, number of characters inthe password or number of bits in the private key), and the randomnessof the secret (for example, an entropy calculation plus, in the case ofa password, whether the password matches a dictionary word). The risk ofobservation during transmission is dependent on factors including, butnot limited to: whether it was transmitted at all (generally, there isno transmission of the secret in PKI); what type of encryption was used,if any, during transmission; and the network used for the transmission(for example, whether it was transmitted using a telephone, an internet,a private network, or other network or communication link or channel).

[0012] The risk of a stored secret being illicitly retrieved isdependent on factors including, but not limited to: the number ofdevices where instances of the secret are stored (for example, a secretmay be stored on a user's PC as well as in a system database); thestorage medium used for each stored instance (hard disk, paper notes,smart card, portable memory device such as a flash memory card, PKCS-11token (as discussed further in “PKCS #11 v2.11: Cryptrographic TokenInterface Standard” published June 2001 by RSA Laboratories, herebyincorporated by reference), or the like); whether the secret is storedin plain text or encrypted; if stored encrypted, the risk associatedwith the encryption key used; what kind of biometrics used, if any, torestrict access to the storage medium; the security of passphrase used,if any, to retrieve secret; the security of biometric system(s) used, ifany, to retrieve secret; and the security of physical token used, ifany, to retrieve secret—for example if a token is used, the security ofthat token is dependent upon whether someone else has had access to it,or if it has been lost or stolen; what combinations of passphrase,biometric, and token are required, if any; and the security of theenrolled biometric template.

[0013] The risk associated with the secret being issued to the wrongperson is dependent on factors including, but not limited to: thespecific method or methods used to verify the user's identity prior toissuing the secret; the degree of human interaction, if any, involved inthe verification process (i.e. is it supervised and verified by atrained human being); what specific biometric system or systems, if any,is used to aid verification; which government agencies (such as forexample the FBI, Secret Service, or other agency), if any, aid in theverification process; and which trusted documents, if any, were requiredfor verification (for example bank statement, social security number,passport, or the like).

[0014] Systems used for e-commerce, online banking and other financiallyrelated areas rely on security to prevent unauthorized users fromaccessing services for monetary gain. For example, well-designed systemstry to prevent would-be buyers from purchasing goods and services withsomeone else's credit card by requiring a PIN or a password.

[0015] More generally, the security and integrity of information systemsdepends primarily on keeping data confidential so that only authorizedusers may see or act against the data, and assuring the integrity ofdata so that the data can not be changed or tampered with undetected.The field of cryptography provides well-known tools for assuringconfidentiality and integrity using encryption techniques such asciphers and hash algorithms.

[0016] One widely known and implemented body of these tools, andprocedures and practices for their use, is called Public KeyInfrastructure (PKI). PKI gets its name from its use of a class ofcryptographic algorithm called a public key algorithm. As is widelyknown to those versed in the cryptographic field, a public key algorithmis a cryptographic algorithm that operates using two different butmathematically-related keys, a public key that may be shared with anyparty and a private key which must be kept secret, such that (for mustsuch algorithms) data encrypted with the public key may only bedecrypted with the private key, and vice-versa. PKI standards are wellknown, X.509 for example, described in Housley, R., “Internet X.509Public Key Infrastructure Certificate and CRL Profile,” RFC 2459,January 1999, and ITU-T Recommendation X.509 (1997 E): InformationTechnology—Open Systems Interconnection—The Directory: AuthenticationFramework, June 1997, both of which are hereby incorporated byreference.

[0017] These standards provide powerful mechanisms for safe and privatestorage and transmission of confidential data so that it remains hiddenfrom unauthorized parties. The standards provide for digital signatures,which provide the receiving party of some data with an assurance of theidentity of the transmitting party. PKI standards further provide fordigital certificates, which provide a tamper-resistant, portable recordof the association of a public key with a person's or organization'sname, attested to and signed by a trusted party, thus presenting a formof unique, irrefutable digital identity or credential for that person ororganization. PKI standards also provide other useful and powerfulmechanisms that can contribute to the security and integrity ofinformation systems.

[0018] PKI is widely used in commercial and non-commercial systems, bothover the Internet and in more closed or local applications. Most webbrowsers, for example, use PKI and PKI-based standards to interoperatewith web servers when high security is desired, as when a user specifiesa credit card number for payment while placing an online order. Theproliferation of electronic commerce has led many jurisdictions aroundthe world to begin to develop legal standards with the intended resultthat a correctly constituted digital signature would be every bit aslegally binding as a handwritten signature is today.

[0019] PKI provides powerful mechanisms, but it has weaknesses. One wayfor digital identities to be compromised is for an impostor to somehowget a copy of the private key that is associated with the public keyembedded in a certificate, thus invalidating an assumption that only theperson or organization to which the certificate is issued has access tothe (secret) private key. Anyone with both the certificate (which ismeant to be public information, freely exchanged with anyone) and theassociated private key (which is meant to be secret) can impersonatesomeone else and compromise the security and integrity of an informationsystem dependent on the valid use of a certificate and associatedprivate key.

[0020] Most systems, therefore, secure the private key such that theuser must authenticate before the private key can be used for any task.Many such systems require a password (“something you know”) or asmartcard (“something you have”), or both. Some systems provideadditional security by putting the private key on a smartcard that isresistant to tampering or copying. Other systems may also employbiometrics (“something you are”) to ensure that the person using theprivate key is in fact the true owner of the certificate.

[0021] However, smart cards may be lost, damaged, or stolen. Passwordsmay be forgotten or guessed. Biometrics systems can be fooled. Theseconcerns are part of what is called in the field “the last-meterproblem”, the problem of making sure that an otherwise secure systemisn't compromised by a failure to correctly authenticate the personusing (and usually physically adjacent to) some part of the system. Thelast-meter problem can present opportunities for impostors in PKIsystems. Mathematically, the theoretical probability of a PKI systembeing fooled or otherwise compromised is extremely low (much less than 1in a billion, for instance). However, once the “last meter problem” istaken into account, the security of such a system is greatly reduced, asthe “last meter problem” becomes the weakest link in an otherwise verysecure chain.

[0022] Today's PKI systems do not take into account the risk associatedwith the “last meter problem” when assessing the trust level toassociate with users of such systems.

[0023] Accordingly, it is an object of the present invention to providean indication of the security of a given transaction.

SUMMARY

[0024] In a first embodiment, the invention provides a transactionconfidence token for use in a secure communication system, comprising anenvelope and a seal. The envelope comprises transaction information anda trust metric. The seal contains a digital signature of the envelope.In preferred embodiments, the envelope further includes a timestamp. Insome embodiments, the transaction information contained in the envelopeincludes a web site address, a web session identifier, a monetary orexchange value, an order number, an SKU number, a credit card number, orany combinations thereof.

[0025] In one embodiment, the trust metric within the envelope is anoverall trust metric indicating a combined confidence level forenrollment, storage, transmission, and authentication processes employedfor authentication of a transaction.

[0026] In another embodiment, the trust metric comprises a storage trustmetric indicating a confidence level for a storage process associatedwith authentication of a transaction. In yet another embodiment, thetrust metric comprises a transmission trust metric indicating aconfidence level for a transmission process associated withauthentication of a transaction. In still another embodiment, the trustmetric comprises an authentication trust metric indicating a confidencelevel for an authentication process associated with authentication of atransaction. In a further embodiment, the trust metric comprises anenrollment trust metric indicating a confidence level for an enrollmentprocess associated with authentication of a transaction. In otherembodiments, a plurality of trust metrics are provided in the envelope.In one embodiment, a first trust metric comprises an overall trustmetric and at least a second trust metric is provided chosen from thegroup consisting of an enrollment trust metric, a storage trust metric,a transmission trust metric, an authentication trust metric, andcombinations thereof.

[0027] In some embodiments, the digital signature contained in the sealis signed with a private key.

[0028] The present invention further provides methods for assuring asecure transaction. In one embodiment, a method for assuring a securetransaction comprises receiving a transaction confidence tokencomprising a trust metric associated with the transaction, determiningif the trust metric indicates a sufficient trust level; and processingthe transaction if the trust metric indicates or exceeds said sufficienttrust level.

[0029] In some embodiments, a method further comprises requiring amitigating factor if said trust metric indicates less than saidsufficient trust level. The mitigating factor may be chosen based on thetrust metric. The mitigating factor may be chosen from the groupconsisting of a fee, a waiting period, an authentication procedure, andcombinations thereof.

[0030] In yet other embodiments, the method further comprises processingthe transaction after receiving a mitigating factor.

[0031] In other embodiments, the method further comprises constructing atransaction confidence token comprising a trust metric, and transmittingsaid transaction confidence token to a server.

[0032] In other embodiments, a method for assuring a secure transactioncomprises receiving a transaction confidence token comprising a trustmetric associated with said transaction, determining if said trustmetric indicates an acceptable risk level; and processing saidtransaction if said trust metric indicates or is less than saidacceptable risk level.

[0033] In some embodiments, the method further comprises requiring amitigating factor if said trust metric indicates greater than saidacceptable risk level. In still other embodiments, the method furtherincludes processing said transaction after receiving said mitigatingfactor.

BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The present invention may be better understood, and its featuresand advantages made apparent to those skilled in the art by referencingthe accompanying drawings.

[0035]FIG. 1 is a schematic representation of one embodiment of atransaction confidence token according to an embodiment of the presentinvention.

[0036]FIG. 2 is a schematic flowchart showing a method of processing atransaction according to an embodiment of the present invention.

[0037]FIG. 3 is a schematic flowchart outlining a process for using atransaction confidence token according to an embodiment of the presentinvention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0038] Many systems today, especially those that use PKI, involvetransactions that depend on keeping a secret protected from use by thirdparties. If there is any risk that the secret is compromised, then thatrisk is propagated to the provider of the transaction itself. Forexample, if an internet-based system allows a user to purchase an itemby entering any valid credit card number, then the risk to the creditcard company or merchant related to an unauthorized purchase isdependent on how well that credit card number can be kept secret, forexample, how well authenticated are the parties to whom the secret ismade available.

[0039] This invention introduces the concept of a software token thatassociates a secret—such as a private key or password—with risk factorsinvolved in protecting that secret from illicit access. Furthermore, inpreferred embodiments of the present invention, the token includes anindication or calculation of the “overall risk of compromise” (OROC),generally represented as an overall trust metric, associated with thesecret. In some embodiments of the present invention, the token alsoincludes a calculation of individual risk factor probabilities used todetermine the OROC, or overall trust metric. This token can then be usedto inform system operators or third parties of the confidence of a givensystem transaction that depends on the secret. A third party can thentake whatever actions it deems appropriate according to the estimatedrisk. For example, in one embodiment of the present invention, the riskfactor is used to deny a transaction if the risk is deemed to great—thatis if the risk factor is greater than a predetermined (or sufficient)value. In another embodiment, the risk factor is used to charge the usera fee in an effort to mitigate the risk, or where some fee may alreadybe charged to the user for the transaction to charge different feesaccording to the assessed risk or trust level. The fee may be a flat feecharged to all transactions having less than a sufficient trust level orthe fee may vary according to the trust level indicated by the token.

[0040] Most authentication systems are geared to answer the question ofwhether the party trying to use the system is the party it claims to bewith either a yes or no, even though the authentication method ormethods employed are imperfect. The present invention provides amechanism for a system to add an estimate of risk or confidence on thatyes or no answer, and for other systems to use that confidenceinformation to their advantage. In one embodiment, it also provides amechanism for documenting the party's identity so as to provide anon-repudiation mechanism for the transaction.

[0041] That is, the present invention provides systems utilizing tokensto assign or mitigate risk.

[0042]FIG. 1 depicts a schematic representation of transactionconfidence token 100 according to one embodiment of the presentinvention.

[0043] A token, such as token 100, is created using availableinformation regarding risk factors, examples of which are discussedabove. Token 100 can be in the form of a separate packet of stored dataassociated with the secret, integrated either with the secret itself or,in the case of PKI, with the associated digital certificate.

[0044] The present invention provides transaction confidence tokenscomprising at least one trust metric. As used herein, ‘trust metric’generally refers to a measure of a risk factor. Examples of typical riskfactors are discussed above. In one embodiment, token 100 comprisesinformation on at least one risk factor discussed above. In anotherembodiment, token 100 comprises an overall risk-of-compromise (OROC)value, or overall trust metric 110, which may take one or more riskfactors into consideration. In a preferred embodiment, token 100 iscreated and stored in a database during both enrollment and subsequenttransactions, includes all the fields shown in FIG. 1. In otherembodiments, only a subset of fields shown in FIG. 1 are present.

[0045] In one embodiment of the present invention, trust metrics, suchas overall trust metric 110, are given by an absolute probabilityranging from 0.0 to 1.0, calculated using a weighted Bayesian equation.Other ranges and equations for calculating trust metrics may also oralternatively be employed. In preferred embodiments of the presentinvention, trust metrics are given by an arbitrary mapping of riskinformation to three categories—low, medium, and high. Any number ofcategories may alternatively be used, with each category represented bya unique indicator. The risk information may alternatively be providedby a continuous range of values rather than in discrete categories.Overall trust metric 110 represents a weighted combination of individualrisk probabilities of a plurality of risk factors. In a preferredembodiment, a system uses token 100 to deny or accept a transaction. Inother embodiments, a system charges a fee, or imposes another mitigationfactor—such as a waiting period or another required authentication—basedon risk information contained in token 100.

[0046] Accordingly, transaction confidence token 100 (FIG. 1) iscomposed of two data structures: envelope 120 and seal 130. Envelope 120comprises transaction contents, or transaction information 140 and atleast one trust metric, although a plurality of trust metrics are shownin FIG. 1. Further, envelope 120 comprises timestamp 150. In a preferredembodiment, transaction information 140 represents a complete record ofa transaction—including, as appropriate, account numbers, web sessionidentifiers, monetary or exchange values, item quantities, an SKUnumber, an order number, a credit card number, a web URL or address, orother data describing the user's authenticated request. In otherembodiments, transaction information 140 comprises only some of theabove information associated with a transaction. In a preferredembodiment, transaction information 140 comprises only a transactionidentifier or reference string such as a web session identifier as isoften used in web applications. In an alternative embodiment,transaction information 140 field comprises a complete transactionconfidence token, which may in turn (i.e., recursively) contain anothertransaction confidence token in its transaction contents field, withoutparticular limit. This embodiment allows for multiple parties to attestto a transaction and attach their own confidence to the transaction asit is processed by each of a number of systems in series. The innermosttransaction confidence token corresponds to the original transactionwhen it is first authenticated and signed by the originating party.Timestamp 150 generally comprises a string indicating a date and time atwhich the authentication event which is the subject of the transactionconfidence token took place. Generally, any time indicator isappropriate for timestamp 150. In a preferred embodiment, timestamp 150is expressed in Universal Coordinated Time (UTC). Overall trust metric110 indicates a degree of overall confidence in a transaction. In oneembodiment, overall trust metric 110 provides a degree of confidence inenrollment, storage, transmission, and authentication processes employedfor authentication of a transaction. Overall trust metric 110 can bedefined according to the specifics of the application contemplated, butin a preferred embodiment, there are three possible values correspondingto low, medium, and high confidence. In a preferred embodiment, lowsecurity refers to a password authentication against a 4-digit numericPIN stored in non-secure storage. Medium security refers to afingerprint authentication or strong password (alphanumeric, mixed case,greater than 8 characters) against a secret in non-secure storage, andhigh security is attributed to a fingerprint authentication or strongpassword against a secret in secure storage such as a smart card.Generally, any number of trust categories can be assigned among anyauthentication processes.

[0047] Envelope 120 may comprise metrics related to measures ofindividual aspects of an authentication process. That is, envelope 120may comprise some or all of the following optional fields: (1)Enrollment Trust Metric 160, (2) Storage Trust Metric 170, (3)Transmission Trust Metric 180, and (4) Authentication Trust Metric 190.

[0048] Enrollment Trust Metric 160 indicates a degree of confidence insecurity of an enrollment or personalization process under which asecret was issued to an authenticating party. Enrollment trust metric160 can be defined according to specifics of the application employed.In a preferred embodiment, there are three possible values correspondingto low, medium, and high confidence. In one embodiment, a low confidenceenrollment trust metric is assigned to self-enrollment where little orno manual verification of user identity is carried out; a mediumconfidence enrollment trust metric is assigned to online verificationusing a “weak secret” such as a credit card number, which may beindependently verified to match the enrollee's name by the credit cardissuer; and a high confidence enrollment trust metric is assigned in anenrollment situation where the user's identity is verified—using trusteddocuments such as a passport, driver's license, or the like—by a humanbeing who works for the enrollment agency or represents anotherpredetermined organization.

[0049] Storage Trust Metric 170 indicates a degree of confidence in thesecurity of a method of storage used to store a secret. Storage TrustMetric 170 can be defined according to the specifics of the applicationemployed. In a preferred embodiment, there are three possible valuescorresponding to low, medium, and high confidence. Here, in oneembodiment, a storage trust metric indicating a low confidence level isassigned to storage of a secret in unencrypted form on a hard disk orFLASH memory of a PC or other computing device; a storage trust metricindicating a medium confidence level is assigned to storage of a secretin encrypted form on a hard drive or FLASH memory of a PC or othercomputing device and protected with a PIN or password; and a storagetrust metric indicating a high confidence level is assigned to storageof a secret in secure storage, such as that of a smart card, andprotected with a PIN or password.

[0050] Transmission Trust Metric 180 indicates a degree of confidence insecurity of a method of transmission, if any, of a secret. ThisTransmission Trust Metric can be defined according to specifics of theapplication employed, but in a preferred embodiment, there are threepossible values corresponding to low, medium, and high confidence. Inone embodiment, a transmission trust metric indicating a low confidencelevel is assigned to a transmission of a secret in unencrypted form viathe internet or local computer network; a transmission trust metricindicating a medium confidence level is assigned to transmission of asecret in encrypted form using SSL or TLS (as known in the art anddescribed further in Dierks, T., and Allen, C., “The TLS ProtocolVersion 1.0,” RFC 2246, January 1999, hereby incorporated by reference)or other common standard of network encryption; and a transmission trustmetric indicating a high confidence level applies to transmission of asecret via armored car using a certified carrier such as, for example,Brink's@, Inc.

[0051] Authentication Trust Metric 190 indicates a degree of confidencein the security of a method of authentication for a particulartransaction. Authentication Trust Metric 190 can be defined according tospecifics of the application employed, but in a preferred embodiment,there are three possible values corresponding to low, medium, and highconfidence. Accordingly, in one embodiment, an authentication trustmetric indicating a low confidence level is assigned to authenticationusing a PIN or password (“something you know”); an authentication trustmetric indicating a medium confidence level is assigned toauthentication using a physical token such as a PKCS-11 standard deviceor smart card (“something you have”); and an authentication trust metricindicating a high confidence level is assigned authentication requiringuse of a biometric such as fingerprint, voiceprint, or face recognition(“something you are”).

[0052] In other embodiments, greater or fewer trust levels are provided.In still other embodiments a continuous range of trust metric values isprovided. In some embodiments, more than one type of procedure, device,or method may be assigned an identical trust metric value. For example,in some embodiments both encrypted and unencrypted storage of a secreton a hard disk receive a trust metric indicating a low trust level,while secure storage of a secret—for example on a smart card protectedwith a PIN—receives a trust metric indicating a high trust level.Although in preferred embodiments, trust metrics provide an indicationof security based on measurable risk factors, in other embodiments trustmetric values are not constrained by theoretical security weaknesses.For example, a particular storage method or enrollment procedure may beassigned a stronger or weaker trust metric based on a preferred orencouraged method for performing those functions.

[0053] Seal 130 of transaction confidence token 100 is a string of bytescontaining a digital signature of envelope 120, signed in a preferredembodiment with the private key of the authenticating party or system.

[0054] In a preferred embodiment, envelope 120 and seal 130 areconstructed according to PKCS #7—for a detailed description of thestandard, see, for example RSA Laboratories. PKCS #7: CryptographicMessage Syntax Standard. Version 1.5, November 1993, hereby incorporatedby reference. Using that standard's signed-data content type such thatenvelope 120 is embodied in a content information (contentInfo) fieldand seal 130 is embodied in a signer information (signerInfos) field.Note that PKCS #7 also allows for the recursion of transactioninformation field 140 of envelope 120 in a transaction confidence token.

[0055] In another embodiment, envelope 120 and seal 130 are constructedaccording to the XML Signature Syntax and Processing Recommendation—fora detailed description of the standard see, for example Eastlake 3^(rd),D., Reagle, J., and Solo, D., “(Extensible Markup Language)XML-Signature Syntax and Processing,” RFC 3275, March 2002, incorporatedherein by reference.

[0056] Other encodings or structures of a transaction confidence tokenare also possible.

[0057] The present invention further provides systems and methods forusing a transaction confidence token. For example, when a requester(client) or server initiates a transaction requiring authentication,such as in step 200 in FIG. 2, server 210 requests the authenticationand an associated transaction confidence token. In other embodiments, nospecific request is made by server 210. During the course of thetransaction Requester 220 allows access to a secret, step 230, such as aprivate encryption key using an authentication method, such as abiometric match. Numerous devices and methods exist for securing asecret, including those described in U.S. application Ser. No. ______,filed ______, entitled “Secure Network And Networked Devices UsingBiometrics” (Attorney Docket No. A-70595/RMA/JML), incorporated hereinby reference. Requester 220 generates, step 240, contents of a requestedtransaction, such as the quantity and SKUs of item(s) to be purchased,in a form suitable to be encoded in the transaction confidence token'stransaction contents, or transaction information field, such astransaction information 140 in token 100 depicted in FIG. 1.

[0058] Requester 220 determines at least one trust metric, step 250, asdescribed above and encodes at least one trust metric in the transactionconfidence token. Requester 220 signs the transaction confidence tokenin step 260. Server 210 receives a transaction confidence tokenassociated with a transaction request in step 270. Server 210 thenadjusts its confidence level, in the transaction, step 280, based onwhether the signature is valid and takes action appropriate to theconfidence level, completing the transaction in step 290.

[0059] The present invention further provides methods for a server toact on a transaction confidence token. FIG. 3 provides a schematicoverview of an embodiment of such a method according to the presentinvention. A server receives a transaction confidence token, step 300,and verifies the signature of the transaction confidence token, step310, using, for example, the public key of the originator of thetransaction confidence token. If the signature verification fails,indicating that the transaction confidence token was not created by thepurported originating party, had been altered after its creation, orotherwise is invalid, then the system may then discard the token, step320, and assume no confidence in the authenticity of the associatedtransaction. In a preferred embodiment, a transaction confidence tokenwith an invalid signature is discarded and the associated transactionrequest is discarded or rolled back according to appropriate exceptionhandling practice for the application employing methods of the presentinvention.

[0060] If the signature verification succeeds, then the serverdetermines its confidence in the transaction, step 330, calculated fromone or more trust metric fields in the transaction confidence token.

[0061] If another Server or plurality of Servers are to participate inthe transaction, step 340, the original receiving server may construct anew transaction confidence token, and embed the current transactionconfidence token, optionally asserting its own degree of confidence inthe transaction, step 350. The server then transmits, step 360, a newtransaction confidence token (comprising embedded first transactionconfidence token) to other participating Server(s), step 370.

[0062] The Server may then do its own processing of the transactionrequest employing the confidence it has determined, step 370. Forexample, if a trust metric within the transaction confidence tokenindicates or exceeds a predetermined sufficient trust level, the serverprocesses the transaction. However, in one embodiment, if a trust metricdoes not indicate a minimum sufficient trust level, the server rejectsthe transaction. If a trust metric indicates a minimum sufficient trustlevel but less than a sufficient trust level, the server may require amitigating factor. For example, the server may require an additionalauthentication procedure, a fee, or a waiting period in an effort tomitigate risk associated with a predetermined range of trust metricvalues.

[0063] Although embodiments of the present invention discussed abovegenerally refer to ‘confidence levels’ or ‘trust levels’ with increasingtrust metric values associated with increasing trust or confidence in atransaction, in other embodiments, trust metrics are assigned andevaluated with respect to risk. That is, risk is generally the oppositeof trust and trust metrics may be assigned such that increasing trustmetric values corresponding to an increasing risk associated with atransaction. In these embodiments, less secure situations would receivea higher trust metric value. For example, in some embodiments of thepresent invention, a confidence level between 0.0 and 1.0 is calculated.A corresponding risk level in this embodiment is given generally by1—(confidence level).

[0064] That is, in another embodiment, if a trust metric within thetransaction confidence token indicates or exceeds a predeterminedmaximum risk level, the risk is determined to be too great, and theserver the server rejects the transaction. However, if a trust metricindicates less than a maximum risk level but greater than an acceptablerisk level, the server may require a mitigating factor before processingthe transaction. For example, the server may require an additionalauthentication procedure, a fee, or a waiting period in an effort tomitigate risk associated with a predetermined range of trust metricvalues. If a trust metric indicates less than an acceptable risk level,the server will process the transaction.

[0065] Having described several methods and procedures, it will beappreciated that the invention may advantageously implement the methodsand procedures described herein on a general purpose or special purposecomputing device, such as a device having a processor for executingcomputer program code instructions and a memory coupled to the processorfor storing data and/or commands. It will be appreciated that thecomputing device may be a single computer or a plurality of networkedcomputers and that the several procedures associated with implementingthe methods and procedures described herein may be implemented on one ora plurality of computing devices. In some embodiments the inventiveprocedures and methods are implemented on standard server-client networkinfrastructures with the inventive features added on top of suchinfrastructure or compatible therewith.

[0066] The foregoing descriptions of specific embodiments and best modeof the present invention have been presented for purposes ofillustration and description. They are not intended to be exhaustive orto limit the invention to the precise forms disclosed, and obviouslymany modifications and variations are possible in light of the aboveteaching. The embodiments were chosen and described in order to bestexplain the principles of the invention and its practical application,to thereby enable others skilled in the art to best utilize theinvention and various embodiments with various modifications as aresuited to the particular use contemplated. It is intended that the scopeof the invention be defined by the claims appended hereto and theirequivalents.

We claim:
 1. A transaction confidence token for use in a securecommunication system, said token comprising: an envelope comprisingtransaction information; and a trust metric; and a seal comprising adigital signature of said envelope.
 2. A token according to claim 1,wherein said envelope further comprises a time stamp.
 3. A tokenaccording to claim 1, wherein said transaction information includesinformation selected from the group consisting of a web site address, aweb session identifier, a monetary or exchange value, an order number,an SKU number, and a credit card number, and combinations thereof.
 4. Atoken according to claim 1, wherein said trust metric is an overalltrust metric indicating a combined confidence level for enrollment,storage, transmission, and authentication processes employed forauthentication of a transaction.
 5. A token according to claim 1,wherein said trust metric comprises a storage trust metric indicating aconfidence level for a storage process associated with authentication ofa transaction.
 6. A token according to claim 1, wherein said trustmetric comprises a transmission trust metric indicating a confidencelevel for a transmission process associated with authentication of atransaction.
 7. A token according to claim 1, wherein said trust metriccomprises an authentication trust metric indicating a confidence levelfor an authentication process associated with authentication of atransaction.
 8. A token according to claim 1, wherein said trust metriccomprises an enrollment trust metric indicating a confidence level foran enrollment process associated with authentication of a transaction.9. A token according to claim 1, wherein said trust metric comprises anoverall trust metric and said envelope further comprises at least onemetric chosen from the group consisting of an enrollment trust metric, astorage trust metric, a transmission trust metric, an authenticationtrust metric, and combinations thereof.
 10. A token according to claim1, wherein said digital signature is signed with a private key.
 11. Amethod for assuring a secure transaction comprising: receiving atransaction confidence token comprising a trust metric associated withsaid transaction; determining if said trust metric indicates asufficient trust level; and processing said transaction if said trustmetric indicates or exceeds said sufficient trust level.
 11. A methodaccording to claim 10, further comprising: requiring a mitigating factorif said trust metric indicates less than said sufficient trust level.12. A method according to claim 11, wherein said mitigating factor ischosen based on said trust metric.
 13. A method according to claim 11,wherein said mitigating factor is chosen from the group consisting of afee, a waiting period, an authentication procedure, and combinationsthereof.
 14. A method according to claim 11, further comprising:processing said transaction after receiving said mitigating factor. 15.A method according to claim 10, further comprising: constructing atransaction confidence token comprising said trust metric; andtransmitting said transaction confidence token to a server.
 16. A methodfor assuring a secure transaction comprising: receiving a transactionconfidence token comprising a trust metric associated with saidtransaction; determining if said trust metric indicates an acceptablerisk level; and processing said transaction if said trust metricindicates or is less than said acceptable risk level.
 17. A methodaccording to claim 16, further comprising: requiring a mitigating factorif said trust metric indicates greater than said acceptable risk level.18. A method according to claim 17, further comprising: processing saidtransaction after receiving said mitigating factor.